An Environment for the Creation of Intelligent Network Services

This paper presents a Service Creation Environment which is unique in o ering global correctness and consistency checks. These guarantee frame conditions for the design concerning implementability, country speci c standards and network speci c features. Frame conditions are formulated in a modal logic and veri ed via model checking. The described environment o ers a lazy and incremental use of formal methods: if no formal constraints are de ned, the system behaves like standard systems for service creation. However, the more constraints are added, the more reliable are the created services. This provides a `soft' entry into the world of formal methods. 1 Service Creation Intelligent Network (IN) services are customized telephone services, like e.g., 1) `FreePhone', where the receiver of the call can be billed if some conditions are met, 2) `Universal Private Telephone', enabling groups of customers to de ne their own private net within the public net, or 3) `Partner Lines', where a number of menus leads to the satisfaction of all desires. The realization of these services is quite complex and error prone. The current trend in advanced IN services clearly evolves towards decoupling Service Processing Systems from the switch network (see e.g. [CrKu94]). The reasons for this tendency lie in the growing need for decentralization of the service processing, in the demand for quick customization of the o ered services, and in the requirement of rapid availability of the modi ed or recon gured services. Service Processing Systems are those elements of the IN architecture which provide service processing logic and control but not connection control and management, which are provided by the underlying switch system. In particular, they include Service Creation Environments1, which are interactive environments responsible for the creation, modi cation, customization and provision of new services. Service Creation Environments for the creation of IN-services are usually based on classical `Clipboard-Architecture' environments, where services are graphically constructed, compiled, and successively tested. Two extreme approaches characterize the state of the art: The rst approach guarantees consistency, but the creation process is strongly limited in its exibility to compose Service Independent Building Blocks (SIBs) to new services. The second approach allows exible compositions of services, but there is little or no feedback on the correctness of the service under creation during the development: the validation is almost entirely located after the design is completed. Thus the resulting test phase is lengthy and costly. This paper presents an environment used for the reliable, aspect-driven creation of telephone services in a `divide and conquer' fashion: initial prototypes are successively 1The Service Creation Environment Function is a major component of the IN architecture ([Aitk95, Q.12xx]). 1 modi ed until each component satis es the current requirements. The entire service creation process is supported by thematic views that focus on particular aspects of the service under consideration. Moreover, the service creation is constantly accompanied by on-line veri cation of the validity of the required features and the executability conditions for intermediate prototypes: design decisions that con ict with the constraints and consistency conditions of the intended service are immediately detected via model checking. Thus, in addition to the facilities o ered by classical `Clipboard'-Architectures', the new approach is characterized by the following three properties: during the entire creation process there exists a current executable prototype that can be tested and animated, the support through thematic views, which provide the required global context and hide unnecessary details, allows the designer to choose a particular aspect of interest, and to develop and investigate the services under that point of view. This supports a much more focused service development, which concentrates on the design of the aspect currently under investigation, the global consistency of each design step with implementation-related or servicedependent frame conditions is automatically veri ed. Thus sources for typical failures can be immediately detected. Figure 1 summarizes the global structure of the MetaFrame approach, which supports an arbitrary decomposition of the design process. This is necessary, since the same Service Creation Environment is shared by teams of users with completely di erent pro les. According to [BoWh94] at least the following user pro les are envisaged: The service programmer has advanced programming skills and uses the SCE to create new generic functions, The service designer has logical skills and uses the above functions to create new services, The service provider is familiar with the speci c customer needs and enters customer speci c data into the data les. The needed design exibility is o ered in MetaFrame by means of the second of the following three phases: 1. In a rst step, an existing service of similar application pro le is loaded from the service library, or a completely new design from scratch is done (under model checking control). Alternatively, initial executable prototypes could automatically be generated from the set of underlying consistency conditions and constraints, a feature, which is not part of the current version of the MetaFrame based service creation environment. 2 2. The second step consists of aspect-driven modi cation: the user chooses the aspect of interest, generates the corresponding view abstracting from all irrelevant details, and modi es it where necessary. This is iterated until all relevant aspects have been treated. Due to the on-line veri cation with the model checker, the executability is preserved and erroneous design steps are immediately detected. 3. Current prototypes can at any time be tested, compiled, executed, and, if satisfactory, stored in a data base. It should be noted that this concept of views generalizes the standard stepwise re nement approaches of the usual tools for service creation, since in particular also the decomposition into subservices has its associated view. In addition, views support the realization of a very exible access control mechanism, by allowing designers and service providers the de nition of customer speci c views with restricted modi cation potential. Views provide in fact a natural division of the central design process (2nd step) into levels. In particular this allows us to tailor the environment for the speci c needs of the service designer, the service provider, the customizer, and the user. The view-speci c hiding can be used to automatically take care of access permissions. After a presentation of the Service Logic Editor in Section 2, the following Sections illustrate its speci c features along a case study. In particular, Section 3 is devoted to the service creation and customization, Section 4 presents the symbolic execution via tracing, and Section 5 shows how to enforce correctness criteria via automatic veri cation based on model-checking. Finally, Section 6 discusses related approaches, Section 7 gives an overview of the MetaFrame environment, of which the Service Logic Editor is an application, and Section 8 reports on the gained experience and gives some perspectives. 2 The Service Logic Editor The design activity described in the previous section is entirely carried out within the IN-Service Logic Editor (SLE), which is used for the creation, display and modi cation of IN-models. The SLE is embedded in MetaFrame (see Section 7), an environment designed for the exible management of large repositories of complex tools which can only be modelled and described at a coarse-grain level. Given an application-speci c repository of tools, the MetaFrame environment supports rapid prototyping as semi-automatic construction of new application-speci c tools from natural language-like `pro les', as well as the inclusion of the new tools into the repository, in a way which does not require much expertise. This leads to an increasingly powerful environment as the constructed tools may also be used in the construction process themselves. The practicability of the approach is enhanced by the fact that user decisions require only knowledge about the speci c application domain. In particular, decision making does not presuppose any familiarity with interna of the 3 system. MetaFrame 's main window (shown in Fig. 3 back) is an interpreter shell. Here commands and programs for the integrated High Level Language interpreter2 can be typed in, but the most important commands and functions are available as pull-down menus and can be activated with mouse clicks. E.g., the File-Menu allows to load and execute HLL les via Load Source and a File select box. Commands, programs, and functions of MetaFrame and of its applications (like e.g. the SLE) are either directly written in HLL, or they are external modules reachable and executable via HLL functions. The SLE is activated via the Graph-Menu of the main window, whose functions allow users to create new service models, or load existing ones through a File select box (Fig. 3 front). SLE windows (see e.g. Fig. 2 middle) allow to build, modify, verify, and execute IN models and views. Interaction is possible either via pull-down menus or via `drag-anddrop' with the mouse. A zoom scrollbar eases the scaling of graphs. The Graph menu deals with the graphs and their representation. E.g. they can be saved as ASCII les in the internal Sgraph-Format [Hims93] or be stored together with the whole window as encapsulated PostScript les. The Layoutmenu o ers several graph layout algorithms, since the `best' visualization of a service depends on its size and structure. The Commands menu is the heart of the development system. It contains the calls to the programs dealing with the simulation, veri cation and with the creation/application of views. These functions are treated in detail in the next sections. The Options menu allows to see the interna of a SIB module by means of the Inspector window (Fig. 4 upper) and to call the hypertext based documentation feature Description (Fig. 4 right). Moreover, SIB List opens a toolbox where the SIB palette is listed (Fig. 2 right) to ease the manual service creation/modi cation. The Help menu contains a summary of the editing modes and commands. SIBs and edges can be placed, selected, dragged, con gurated, deleted etc. The next Sections illustrate on a concrete example the features of the system. In particular, they follow a user session in the development, con guration, testing, and veri cation of a new service. 2The High Level Language (HLL) is a PASCAL-like imperative programming language designed for the combination of complex program fragments and modules available in some software library. 4 3 Creating a New IN-Service: Granny's Freephone The service now under development is a simple kind of freephone (800-service). The aim is to design a service for grannies who would like to incentivate friends and relatives to call them by paying their calls if they are done at a convenient time of the day. The development follows the lines already suggested in Fig. 1. Services are currently either created from scratch, or obtained by modi cation of pre-existing similar services stored in a Service Library. The fully automatic synthesis of services from a speci cation and a set of consistency rules is possible in MetaFrame , but not yet integrated in the SLE application. To enter the service creation, the designer calls the SLE from the MetaFrame main window either by asking for a New SNI Graph, which results in an empty IN-model window, in case he intends to design the new service from scratch; otherwise he can load existing services from the Service Library via Load SNI Graph. Services can be built interactively as graphs of SIBs. The SIB palette available in the database is called with the option SIB List and is shown in the window of Fig. 2 right. This way, graphs like the one shown in Fig. 2 are developed. They establish the service logic, which is a rather abstract sketch of the service. In the Granny's Freephone example, the logic is the following: after a call initialization section common to all services, the caller dials the granny's speci c freephone number, then he is prompted to enter a personal identi cation number (PIN) and, depending on the time of the day, the call is either released (in the forbidden time windows) after an announcement, or it is routed to the desired destination number. The complete service logic is shown in Fig. 5. 3.1 The Hypertext System An on-line documentation via hypertext o ers at any stage of the service creation comfortable information about each SIB. This feature is activated via the Description command in the SLE window. It shows for each SIB a hypercard like the one of Fig. 4(right). The Description part contains documentation text as well as the HLL code which is executed during animation via red-line-tracing. The buttons call navigation functions (step back, consult the history of visited cards, step forward in the history), as well as editing functions (open a new card, edit or delete the current card). 3.2 Service Customization The Service Creation of the previous section only established the coarse structure of the service in terms of the sequences of SIBs which are encountered during the possible runs, but the program is still nondeterministic: the branching conditions have in fact still to be established. Such branching conditions are SIB-speci c edge parameters. The con guration of SIB-speci c branching conditions is possible through an Inspector window (Fig. 4 middle), which shows in particular the list of possible exit options of a 5 selected SIB. For a correct con guration, all the exit options shown in the list have to be assigned by mouse clicks to an actual outgoing edge of the SIB. Fig. 4 shows a snapshot of the con guration of the Granny's Freephone service. Here, the labelled edges have already been con gured, and it is now the turn of the timedependent-routing SIB. Five time intervals are lseparately dealt with, of which the rst two have been assigned to the left outgoing edge, the fourth and fth have just been selected and are about to be assigned to the right outgoing edge. The remaining two options have to be assigned to some edge too before the con guration of this SIB is completed. When the options list is empty, the con guration is complete and unlabelled outgoing edges become deactivated together with the now unreachable portions of the graph. Undo is always possible and revives the deactivated portions. Unreachable nodes and subgraphs can be either physically removed or made invisible. While the rst operation is persistent, the second can be undone. The status of edges and options during the con guration is evidenced by colour coding: con gured edges are green, not-yet-con gured ones are red, and deactivated ones are blue. The fully speci ed and con gured service is shown in Fig. 5. The simple but comfortable editing functionality described above is complemented in the tool by (standard) symbolic execution, via animation of the IN models (red-line-tracing), formal veri cation, via model checking and abstract interpretation. These two techiques can be called at any time during the service creation, in order to check the consistency of the service designed so far. They are summarized in the following two sections. 4 Animating IN Services The animation of IN services (also called red-line tracing) is used during the service creation in order to detect design or con guration errors via symbolic execution of the service under design. This feature is present also in some Clipboard-Architecture based environments, where it constitutes the only way of testing the correctness of the development. Animation is realized via the HLL interpreter. Every SIB speci cation contains HLL code which is executed when the control ow reaches a node with that SIB. This HLL code is also visible in the hypertext descriptor window of the SIB (shown in Fig. 4 for the sf time-dependent routing SIB). The control ow is determined by the service environment and by the user's input data. The animation is activated via the menu command Trace Service. The path in the graph taken by the symbolic run is colored in red (hence the name). Required user input is asked for by input windows and the control ow is directed according to the input values. Figure 5 shows an example of trace execution for the Granny's Freephone: clockwise, 6 (a) the user is asked to complete the simulation environment by input of the call's time and (b) of the special number the Granny's Freephone corresponds to, then he is (c) asked to give his Personal Identi cation Number, which is found to be incorrect. (d) After the corresponding announcement, he gets (e) a new chance (max 3 times). This time the PIN is correct, and since the time of the call lies within the allowed time intervals, (f) the call is routed to Granny's actual phone number, and (g) the simulation run terminates. An exhaustive check even of small size services like the Granny's Freephone is not feasible, because of the size of the underlying data domains. In spite of this, many large services (more than a hundred SIBs and several hundreds of edges) have had to be validated with similar simulation-based methods in the past. The validation was limited to a representative, but not exhaustive set of test cases, and was performed with high costs in terms of required man/months and of delayed availability of the service on the market. Here the introduction of formal veri cation techniques o ers a sound and economically valuable alternative. 5 Formal Veri cation Orthogonal to the prototype animation, the environment provides automatic veri cation features based on formal methods. Two kinds of correctness checks can be distinguished: the local correctness of a SIB con guration is checked and/or enforced during the con guration phase. E.g., no options of a SIB can be left unassigned, each option can be assigned to only one edge (nondeterminism is not allowed here), unparameterized outgoing edges and their subgraphs are removed, and lots of other special cases, global correctness and consistency of the con guration can be checked between the elementary con guration steps for the single SIBs. They concern the interplay between the SIBs of a service. In fact, the correctness of a SIB con guration wrt. some prede ned set of properties can be veri ed at any time via model checking in a push-button fashion. While local checks are quite straightforward to implement, and are present also in other Service Creation Environments, the MetaFrame based Service Creation Environment is unique in o ering global correctness and consistency checks. The remainder of this section will therefore concentrate on the latter. 7 A property is global if it does not only involve the immediate neighbourhood of a SIB in the Service Logic graph3, but also relations between nodes which may be arbitrarily distant and separated by arbitrarily heterogeneous subgraphs. The treatment of global properties is required in order to capture the essence of the expertise of designers about do's and don'ts of service creation, e.g. which SIBs are incompatible, or which can or cannot occur before/after some other SIBs. Such properties are rarely straightforward, sometimes they are documented as exceptions in thick user manuals, but more often they are not documented at all, and have been discovered at a hard price as bugs of previously developed services which obstinately did not want to obey the known rules. They build exactly the kind of precious domain-speci c knowledge that expert designers accumulate over the years, which is particularly worthwhile to include in the design environment for future automatic reuse. In the presented environment, such properties are gathered in a Constraint Library, which can be easily updated and which is automatically accessed by the model checker during the veri cation. Here the model checker of [SCKK95] is used, which veri es whether a given model satis es properties expressed in a modal logic called the modal mu-calculus [Koze83]. In the IN setting: the properties express correctness or consistency constraints the target IN service is required to respect. They are expressed in a user friendly, natural language-like macro language, which is based on the temporal logic SLTL (Semantic Linear Time Logic, cf. [StMF93]). This is a linear-time variant of Kozen's mu-calculus [Koze83], which comes together with e cient veri cation tools based on model checking; the models are the service logic graphs, where SIB names correspond to atomic propositions, and branching conditions correspond to action names in the SLTL formulas. The veri cation module is called via the menu command Model Check. A lename is input via le selector box. The le contains the properties to be checked expressed as formulas of SLTL. If the model checker detects an inconsistency, a plain text explanation of the violated constraint appears in a window as in Figure 6, and an error view is automatically generated, which evidences only the nodes which are relevant to detect the error. Corrections can be done directly on the error view and the subsequent view application transmits the modi cations to the concrete model (cf. 5.1). In the example, model checking the service shown in Fig. 6 results in the discovery of erroneous paths in the graph, which violates the constraint shown in the same Figure in the rightmost window: On each segment (phase) of the calls, a bill should be issued before the system can charge for the segment. The problematic part of the paths starts at the prompt node marked by the arrow, whose icon is framed in red. The correction of the error is eased by the use of abstract views. 3I.e., the set of all the predecessors/successors of a node along all paths in the graph. 8 5.1 Abstract Views Views are abstract service models. As such, they show aspects of actual, concrete models. They are used to hide any aspect of an IN model which is irrelevant wrt. an intended operation. This is useful during the development phase in order to concentrate on speci c themes, e.g., the billing or the user-interaction contained in a service, while abstracting from all the rest. This is a solution to the problem of the growing size of the services, which may contain several hundreds of nodes, and which are in their whole unmanageable. In the same way, views can also embody a very exible access policy: only the nodes a user is allowed to touch are left concrete. Operationally, views do not di er much from the actual IN models. E.g. they can be loaded and edited in the usual way, however, often with quite dramatic e ects: minor modi cations on views may correspond to radical structural changes of the underlying concrete model. In addition, views can be edited and then applied to the underlying concrete model, where application corresponds to the concretization function in Fig. 1. The interplay between abstract views and their concrete model will be illustrated in the next section. Examples for view-speci c operations are Create View for computing the view corresponding to an abstraction function (cf. Fig. 1) which has been selected via a File select box. The result is displayed in a new SLE window. Views can be edited (with decapsulations of abstract nodes, where needed) and then applied to the concrete model via Apply View, which implements the concretization function (cf. Fig. 1), or view modi cations may be ignored via Remove View. Execution of a view means execution of the underlying concrete model. It implicitly requires its application. The design error in the example is now going to be corrected with the help of an error view. The error view of Fig. 7 has been obtained automatically after the failed model checking. The view concentrates on the important nodes for the error diagnosis. All the SIBs which are irrelevant for the detection of this error have been automatically abstracted away and are collapsed in the unlabelled nodes. It is now easy to see that the path between the prompt and the calling-line-charging SIBs evidenced by the arrows contains a calling-line-charging which has no corresponding billing node. The location of the error is much more easily spotted. Fig. 8 shows the results of the error correction: the view graph has been edited, by inserting the billing node marked by the arrow in appropriate position on the segment. 9 The Apply view command actualizes the corresponding IN-service model (see Fig. 9) which is thus automatically corrected. A new veri cation via model checking conrms the correctness of the corrected service. Of course this is a simple example, which could have been easily handled by hand, but current IN services have reached sizes and complexities which demand for automated support for error detection, diagnosis, and correction. 6 Related Approaches Three service creation environments have been recently presented: The environment by [BoWh94] is based upon a visual service de nition (VSD) providing a graphical representation of a service. The service logic is constructed in a drag and drop approach from available icons representing service elements. The output of an element is checked for its consumability by its successor. VSD then generates the service logic in a meta-representation, which can be input to several components of the IN architecture. The metales are managed by the SCE workbench, which keeps track of the de ned services and of their components. The SIB approach described in [WrSy94] provides a simulated IN environment to develop and test new services. Several steps are necessary to create service logic program instances (SLPIs) from SIBs. After the services have been developed in the simulation environment, additional tests of the new services are required in the life environment replacing simulated components. The simulated execution environment supports events coming from switches, intelligent peripherals (IPs) and service management systems. [SLKF94] presents a system for handling a multitude of IN components as targets of the service creation process, which is built along a well-known intermediate language approach of the compiler's world: the output of the service generation tool is translated into an intermediate language (AOPL: application-oriented parsing language), from which code generators generate target code for speci c IN components such as Service Control Points or Intelligent Peripherals. In contrast, the MetaFrame approach concentrates on the reliability of the design by means of an on-line automatic control in order to allow the detection of erroneous parts already in early design phases. In combination with the traditional features and the new error correction support, this drastically reduces the `time to market'. 7 The MetaFrame Environment MetaFrame is a meta-level framework designed to o er sophisticated support for the systematic and structured computer aided generation of application-speci c complex objects 10 from collections of reusable components. Figure 10 shows its overall organization. Specialcare has been taken in the design of an adequate, almost natural-language speci cationlanguage, of a user-friendly graphical interface, of a hypertext based navigation tool, inthe automation of the synthesis process, and of the repository management.This application independent core is complemented by application-speci c libraries ofcomponents, which constitute the objects of the design. The principle of separating thecomponent implementation from its description is systematically enforced: for each appli-cation there is a distinct Meta-Data repository containing a logic view of the components.The tools themselves and their documentation are available in a di erent repository. Thisorganization o ers a maximum of exibility since the MISS synthesis core is independentof the direct physical availability of the tools (except for the execution, which is a di erentmatter).Additional features like e.g. the advanced data and project management features (al-ready o ered by object oriented CAD frameworks as NELSIS [WoBD90]), could be inte-grated with little e ort.The resulting MetaFrame allows a designer the rapid and reliable realization of e -cient application speci c complex tools without a sophisticated user interaction, and istherefore an ideal means for a systematic investigation and construction of adequatelydesigned tools for speci c problem structures.The current experience has shown the practicability and the exibility of the MetaFrameapproach in several other areas of application:CATS: automatic generation of complex tools from a repository of components[MaCS95, StMC95b],CompGen: determination of the correct ordering of the individual analyses andoptimizing transformations in a data ow analysis/program optimization setting[KnRS95],CUTIP: automatic con guration of complex UNIX R4 piping sequences for textand image processing [SFCM94, SFCM95] (DaCapo project, in cooperation withFORWISS5),StatEval: automatic generation of tools for the exible evaluation of statistic data(in preparation).AsMetaFrame is an open system, it can easily be extended and modi ed to include furthertools, to realize a highly distributed environment where tools are retrieved at need, andto cover other application areas. These properties are particularly important in emergingand growing areas like the development of distributed systems, telecommunications, and4UNIX Ris a registered trademark in the United States and other countries, licensed exclusivelythrough X/OPEN Company Ltd.5Bavarian Research Institute for Knowledge Based Systems11 Hardware/Software codesign, where the integration of heterogeneous domains is a keypoint.8 Experience and PerspectivesThe presented approach exactly meets the demands recently expressed by Goguen andLuqi in [GoLu95] for the emerging paradigm of Domain Speci c Formal Methods: Theessence of their proposal is to use formal methods on a large or huge grain level ratherthan on elementary statements, thus to support the programming with whole subroutinesand modules as the elementary building blocks. This is precisely what MetaFrame isdesigned for and what the application to IN services embodies.Still, the step towards the use of formal methods is rather big and can hardly be done atonce. The MetaFrame environment therefore o ers a lazy and incremental use of formalmethods: if no formal constraints are de ned, the system behaves like standard systemsfor service creation. However, the more constraints are added, the better is the automaticcontrol and the more reliable are the created services. In fact, in the extreme case of afull speci cation of the vital frame conditions, very few representative tests are requiredto guarantee the correctness of the service.Experience shows that it is often impossible to write complete formal speci cationsin practice. E.g. in the case of service creation, the knowledge about the exact require-ments is distributed over several groups along the development process, and it is onlyused implicitely during the development. Thus people need to learn that and how thisknowledge should be made explicit, e.g. via constraints. The MetaFrame approach oflazy or incremental formalization takes this situation into account by providing a `soft'entry into the world of formal methods.AcknowledgementsWe are grateful to Michael von der Beeck, Achim Dannecker, Philipp Florschutz, CarstenFriedrich, Andreas Holzmann, Marion Klein, Dirk Koschutzki, Gerald Luttgen, FalkSchreiber, Markus Schweighofer, and Matthias Seul for their cooperation in the designand implementation of MetaFrame . We also thank the Siemens Nixdorf IN team andthe GMRS team for their precious interaction in the de nition of the characteristics ofthe system and for their valuable contributions to the realization of the current product.References[Aitk95] J. Aitken: \Intelligent Networks", Seminar, Logica UK Ltd., London, April26{27, 1995.12 [BoWh94] P. K. Bohacek, J. N. White: \Service Creation: The Real Key to IntelligentNetwork Revenue", Proc. Workshop Intelligent Networks '94, Heidelberg, May24-26, 1994.[ClKS92] R. Cleaveland, M. Klein, B. Ste en: \Faster Model Checking for the ModalMu-Calculus," Proc. of CAV'92, LNCS 663, Springer Verlag, 1992.[ClPS93] R. Cleaveland, J. Parrow, B. Ste en: \The Concurrency Workbench: Asemantics-based veri cation tool for nite state systems," ACM TOPLASVol.15, N.1, 1993, pp.36-72.[CrKu94] E. Crabill, J. Kukla: \Service Processing Systems for AT&T;'s Intelligent Net-work", AT&T; Technical Journal, Vol.73, N.6, Nov./Dec.1994, pp.39-47.[FrMS94] B. Freitag, T. Margaria, B. Ste en: \A Pragmatic Approach to Software Syn-thesis", ACM SIGPLANWorksh. on Interface De nition Languages, Portland,Oregon, January 1994, also in ACM SIGPLAN Notices.[GoLu95] J.A. Goguen, Luqi: \Formal Methods and Social Context in Software Devel-opment," (invited talk) 6th Int. Conf. on Theory and Practice of SoftwareDevelopment (TAPSOFT'95), Aarhus (Denmark), May 1995, LNCS N.915,pp.62-81.[Hims93] M. Himsolt: \Sgraph Programmer's Manual", Universitat Passau, 1993.[KnRS95] J. Knoop, O. Ruthing, B. Ste en: \The power of assignment motion.," Proc.of the ACM SIGPLAN'95 Conf. on Programming Language Design and Im-plementation (PLDI'95), La Jolla, California, June 18-21, 1995, SIGPLANNotices 30, 6 (1995), pp.233-245.[Koze83] D. Kozen: \Results on the Propositional -Calculus", Theoretical ComputerScience, Vol. 27, 1983, pp. 333-354.[Q.12xx] ITU CS1 Recommendations, 1993.[MaCS95] T. Margaria, A. Cla en, B. Ste en: \Computer Aided Tool Synthesis in theMETA-Frame ", 3. GI/ITG Workshop on \Anwendung formaler Methodenbeim Entwurf von Hardwaresystemen", Passau (Germany), March 1995, pp.11-20, Shaker Verlag.[Oust94] John K. Ousterhout: \Tcl and the Tk Toolkit," Addison{Wesley, April 1994.[SCKK95] B. Ste en, A. Cla en, M. Klein, J. Knoop. T. Margaria: \The Fixpoint Anal-ysis Machine", to be presented at the 6th Int. Conference on Concurrency(CONCUR'95), Philadelphia (PA), August 21-24, 1995.13 [SFCM94] B. Ste en, B. Freitag, A. Cla en, T. Margaria, U. Zukowski: \IntelligentSoftware Synthesis in the DaCapo Environment," Proc. 6th Nordic Worksh.on Programming Theory, Aarhus (DK), Oct. 1994, BRICS Report N.94/6.[SFCM95] B. Ste en, B. Freitag, A. Cla en, T. Margaria, U. Zukowski: \An Approach toIntelligent Software Library Management", Proc. 4th Int. Conf. on DatabaseSystems for Advanced Applications (DASFAA '95), National University ofSingapore, April 10-13, 1995.[SLKF94] Lev Slutzman, Hui-Lan Lu, Marc P. Kaplan, Igor Faynberg: \AchievingPlatform-Independence of Service Creation Through the Application-OrientedParsing Language", Proc. Workshop Intelligent Networks'94, Heidelberg, May24-26, 1994.[StMC95] B. Ste en, A. Cla en, T. Margaria: \The MetaFrame : An Environment forFlexible Tool Management," 6th Int. Conf. on Theory and Practice of SoftwareDevelopment (TAPSOFT'95), Aarhus (Denmark), May 1995, LNCS N.915,pp.791-792.[StMC95b] B. Ste en, T. Margaria, A. Cla en: \Heterogeneous Analysis and Veri cationfor Distributed Systems", Techn. Rep. MIP 95-09, Fakultat fur Mathematikund Informatik, Universitat Passau (Germany), July 1995.[StMF93] B. Ste en, T. Margaria, B. Freitag: \Module Con guration by Minimal ModelConstruction," Techn. Rep. MIP 93-13, Fakultat fur Mathematik und Infor-matik, Universitat Passau (Germany), December 1993.[WoBD90] P. van der Wolf, P. Bingley, P. Dewilde: \On the Architecture of a CADFramework: The NELSIS Approach," Proc. EDAC'90, IEEE Computer Soci-ety Press, pp.29-33.[WrSy94] Mike Wrax, Mark Syrett: \Service Creation Using the Hewlett-Packard ServiceCreation Environment", Proc. Workshop Intelligent Networks'94, Heidelberg,May 24-26, 1994.14